ci(docker): allow a manual rebuild via workflow_dispatch - #129

…ships

The image installs requirements.lock with --require-hashes, but four
workflows still installed requirements.txt, whose >= ranges resolve to
the newest PyPI releases. So CI tested, and the SBOM described, versions
the image does not ship.

lint-and-test: installs requirements-dev.txt with the lockfile's pins as
constraints. SQLAlchemy 2.1.0 reached CI unpinned and failed a test on
every branch while the image stayed on 2.0.52. The hashes are stripped
into $RUNNER_TEMP/constraints.txt because pip switches the whole install
to --require-hashes as soon as one constraint carries a hash (checked
with pip 26.2.1), and the dev tools are unhashed. The step fails if any
lockfile entry does not become a constraint, instead of letting it
install unpinned. The dev-only tools are not in the lockfile: a pip
dry-run for cp314/manylinux resolves them to the same pytest, ruff, uv,
aiosqlite, httpx, pip-audit, pyinstaller and bs4 versions as without
constraints, and 76 of the 77 locked packages at their locked version
(uvloop, Linux-only, was skipped on the Windows host that ran it).
A floor raised past the locked version (the usual Dependabot pip PR) now
fails this install as well as lockfile-drift; recompiling fixes both. A
dev tool that needs a newer locked package fails here with
lockfile-drift green; the ci.yml comment gives the --upgrade-package
recompile for that case.

deps-latest (new): the unpinned install plus pytest, weekly on Mondays
and on demand, gating nothing. It keeps the early warning that caught
2.1 before any lockfile bump. Not a continue-on-error job in ci.yml:
that still shows a red check on every PR whenever upstream breaks.

sbom / release: the SBOM described the runner's own Python after
`pip install -r requirements.txt` plus cyclonedx-bom. main's SBOM at
1d7bad6 had 106 components against 77 in the lockfile: 19 at versions
the image does not contain, 28 from the generator itself, and packaging
downgraded from 26.3 to 25.0 by the generator's install. Now: a fresh
venv installed the Dockerfile's way, the generator outside it, and
`cyclonedx-py environment <venv python>` (checked with cyclonedx-bom
5.5.0). Rejected `cyclonedx-py requirements requirements.lock`: it
parses the hashed lockfile fine but emits no licences and no dependency
graph (main's SBOM carries 70 licensed components, 61 graph entries).
The docs now say which workflow builds the release SBOM (release.yml,
not sbom.yml) and that system packages are not in it.

verapdf: built its PDF/A fixture with the newest pikepdf; it now
installs the lockfile the image's way (all 77 locked versions have
cp314 manylinux wheels). build-desktop.yml still installs
requirements.txt: it builds on Windows, the lockfile is Linux-only.

docker.yml: renormalized to LF. PR #129 committed it with CRLF via an
API commit despite `*.yml text eol=lf`, so every checkout showed it as
modified. No content change.

tests/test_supply_chain_hygiene.py pins all of it, including that
deps-latest keeps lint-and-test's system packages and pytest call; each
of 10 simulated reverts fails a guard.

Local suite 1225 passed, 63 skipped (native-library tests run in CI);
ruff clean; python-version gate green; i18n and pip-audit inputs
untouched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ships

The image installs requirements.lock with --require-hashes, but four
workflows still installed requirements.txt, whose >= ranges resolve to
the newest PyPI releases. So CI tested, and the SBOM described, versions
the image does not ship.

lint-and-test: installs requirements-dev.txt with the lockfile's pins as
constraints. SQLAlchemy 2.1.0 reached CI unpinned and failed a test on
every branch while the image stayed on 2.0.52. The hashes are stripped
into $RUNNER_TEMP/constraints.txt because pip switches the whole install
to --require-hashes as soon as one constraint carries a hash (checked
with pip 26.2.1), and the dev tools are unhashed. The step fails if any
lockfile entry does not become a constraint, instead of letting it
install unpinned. The dev-only tools are not in the lockfile: a pip
dry-run for cp314/manylinux resolves them to the same pytest, ruff, uv,
aiosqlite, httpx, pip-audit, pyinstaller and bs4 versions as without
constraints, and 76 of the 77 locked packages at their locked version
(uvloop, Linux-only, was skipped on the Windows host that ran it).
A floor raised past the locked version (the usual Dependabot pip PR) now
fails this install as well as lockfile-drift; recompiling fixes both. A
dev tool that needs a newer locked package fails here with
lockfile-drift green; the ci.yml comment gives the --upgrade-package
recompile for that case.

deps-latest (new): the unpinned install plus pytest, weekly on Mondays
and on demand, gating nothing. It keeps the early warning that caught
2.1 before any lockfile bump. Not a continue-on-error job in ci.yml:
that still shows a red check on every PR whenever upstream breaks.

sbom / release: the SBOM described the runner's own Python after
`pip install -r requirements.txt` plus cyclonedx-bom. main's SBOM at
1d7bad6 had 106 components against 77 in the lockfile: 19 at versions
the image does not contain, 28 from the generator itself, and packaging
downgraded from 26.3 to 25.0 by the generator's install. Now: a fresh
venv installed the Dockerfile's way, the generator outside it, and
`cyclonedx-py environment <venv python>` (checked with cyclonedx-bom
5.5.0). Rejected `cyclonedx-py requirements requirements.lock`: it
parses the hashed lockfile fine but emits no licences and no dependency
graph (main's SBOM carries 70 licensed components, 61 graph entries).
The docs now say which workflow builds the release SBOM (release.yml,
not sbom.yml) and that system packages are not in it.

verapdf: built its PDF/A fixture with the newest pikepdf; it now
installs the lockfile the image's way (all 77 locked versions have
cp314 manylinux wheels). build-desktop.yml still installs
requirements.txt: it builds on Windows, the lockfile is Linux-only.

docker.yml: renormalized to LF. PR #129 committed it with CRLF via an
API commit despite `*.yml text eol=lf`, so every checkout showed it as
modified. No content change.

tests/test_supply_chain_hygiene.py pins all of it, including that
deps-latest keeps lint-and-test's system packages and pytest call; each
of 10 simulated reverts fails a guard.

Local suite 1239 passed, 63 skipped (native-library tests run in CI);
ruff clean; python-version gate green; i18n and pip-audit inputs
untouched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>